TF-M sources integration to Mbed-OS #9653

mikisch81 · 2019-02-11T08:01:35Z

Description

This PR introduces TF-M sources into Mbed-OS according to ISGDEVPREQ-1027.

TF-M sources were imported into mbed-os tree using the same Importer script as CMSIS, afterwards a series of patches were applied which fix some issues and align the code to work with Mbed-OS.

The TF-M sources were imported from the feature-ipc branch of the TF-M repository, hash 45e5276bc04036654693cbf335829aa15a64ed5f.

Commit 34433bc added a manifest json file which lists the files/folder needed to import and a list of SHAs to apply afterwards.

We did not import TF-M partitions (Crypto, Attestation, etc..) as we are re-using the existing partitions in Mbed-OS (Internal-storage, PSA-Crypto and Platform), commit 42d8f2b adds an auto-generation tool which generated in
commit c855263 all the partitions' header files needed by TF-M core.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[X] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Release notes

The PSA program offers a reference implementation (TF-M) aimed at facilitating the deployment of PSA among RTOS vendors. TF-M is an OS-agnostic project, it presents generic methods to achieve PSA secure partitioning and offer PSA secure services like attestation, secure storage, or crypto. Integrating TF-M allows Mbed OS to achieve PSA compatibility.

Mbed OS has imported the TF-M core to be used by its' own secure services.

Currently only v8m targets can run TF-M, for porting TF-M to be used by a target please refer TF-M integration guide.

Reviewers

@gaborkertesz @ashok-rao @deepikabhavnani @ARMmbed/mbed-os-psa @ARMmbed/mbed-os-tools

ciarmcom · 2019-02-11T10:00:51Z

@mikisch81, thank you for your changes.
@deepikabhavnani @ashok-rao @ARMmbed/mbed-os-tools @ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers please review.

ciarmcom · 2019-02-11T12:00:42Z

@mikisch81, thank you for your changes.
@deepikabhavnani @ashok-rao @ARMmbed/mbed-os-tools @ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers please review.

ciarmcom · 2019-02-11T14:01:05Z

@mikisch81, thank you for your changes.
@deepikabhavnani @ashok-rao @ARMmbed/mbed-os-tools @ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers please review.

deepikabhavnani

Thanks for splitting. Looks good to me 👍

0xc0170 · 2019-02-11T17:14:37Z

[X] Functionality change

Please add release notes section, following https://os.mbed.com/docs/mbed-os/v5.11/contributing/workflow.html#functionality-change

cmonr · 2019-02-11T22:42:02Z

@mikisch81 Good news!

Last 7 commits are from pending PRs to Mbed-OS and should not be reviewed here:

Those two PRs are now merged in to Mbed OS, so rebasing this PR will make them disappear from this PR!

Please do so to make review of this PR a bit cleaner.

mikisch81 · 2019-02-12T07:16:02Z

Rebased this PR on top of master to get all the dependent PRs in.

mikisch81 · 2019-02-12T09:31:42Z

Latest update removes the workaround we did in crypto partition and adds another patch to TF-M sources which fix an internal TF-M issue.

mikisch81 · 2019-02-12T10:31:45Z

@0xc0170 Added release notes

bridadan

The tools/tfm folder looks very similar to the existing tools/spm code in terms of the json and py files. Are there plans to merge these in a coming PR? Lots of the code appears to be duplicated.

bridadan · 2019-02-12T21:39:55Z

components/TARGET_PSA/services/psa_prot_internal_storage/pits_psa.json

@@ -3,8 +3,8 @@
    "type": "APPLICATION-ROT",
    "priority": "NORMAL",
    "id": "0x0000000A",
-    "entry_point": "pits_entry",
-    "stack_size": "0x400",
+    "entry_point": "its_entry",


Was this rename intentional?

yes, ITS is the correct name

bridadan · 2019-02-12T21:56:29Z

tools/tfm/partition_description_schema.json

@@ -0,0 +1,196 @@
+{


This file is identical to the file found here: https://github.com/ARMmbed/mbed-os/tree/master/tools/spm

it's basically is a duplicate with minor changes, we'll remove the unneeded duplicates

bridadan · 2019-02-12T22:00:03Z

tools/tfm/__init__.py

@@ -0,0 +1,23 @@
+# Copyright (c) 2017-2018 ARM Limited


This file is identical: https://github.com/ARMmbed/mbed-os/blob/master/tools/spm/__init__.py

bridadan · 2019-02-12T22:00:35Z

tools/tfm/generate_partition_code.py

@@ -0,0 +1,689 @@
+#!/usr/bin/python


This file shares most of the same codes as this one: https://github.com/ARMmbed/mbed-os/blob/master/tools/spm/generate_partition_code.py

There are a decent amount of changes though.

Eventually everything under tools/spm will be removed when TFM will support dual-core, it will be easier to remove if it does not share stuff with tools/tfm.

bridadan · 2019-02-12T22:02:07Z

components/TARGET_PSA/TARGET_TFM/COMPONENT_SPE/autogen/tfm_partition_defs.inc

@@ -0,0 +1,37 @@
+/* Copyright (c) 2017-2019 ARM Limited


General question: any reason for going with .inc instead of .h? Mbed OS generally sticks with .h I believe.

+1
The only other file that uses a .inc suffix in Mbed OS is features/FEATURE_BLE/targets/TARGET_CORDIO_LL/thirdparty/uecc/asm_arm.inc, and even that's third party.

These are the partition header files used by TF-M.
TF-M actually generated these files according to their secure partitions manifests.
But because we use our own partitions we need to generate those headers ourselves.
So in order not to change TF-M imported code we keep the same suffix.

So in order not to change TF-M imported code we keep the same suffix.

~~Good enough for me!~~

Actually, I'm not even sure if our build system picks up .inc files. Looking here: https://github.com/ARMmbed/mbed-os/blob/master/tools/resources/__init__.py#L413-L432

Seems like it won't be brought in as an include directory, does that sound right @theotherjimmy ?

@mikisch81 I believe that's working because there are other .h files present in the directory, so it is being picked up as an include path. If you removed all of the other .h files and just had .inc files, I don't believe the build system would keep that directory as an include path.

One of the generated files is an .h file, so you are probably right, but all these files are generated together and shouldn't move or change afterwards.
We can ask TFM why the inc extension instead of regular .h.

@bridadan We really need to avoid changing imported TF-M code, the only exceptions should be blocking issues (like bugs or porting issues).

If this is a TF-M imported thing then I understand. We should get an issue filed to add .inc to our list of header file types in our build system.

PR up for this issue: #9715

cmonr · 2019-02-12T22:14:37Z

.astyleignore

@@ -22,4 +22,5 @@ TESTS/mbed_hal/trng/pithy
 targets
 components/802.15.4_RF
 components/wifi
+components/TARGET_PSA/TARGET_TFM


@ARMmbed/mbed-os-maintainers Heads up, another large block of code that's about to be ignored by astyle

Might need to talk with techleads about why components seems to be special in regards to code styling.

Everything under TARGET_TFM is imported from an external source, so it should be ignored by astyle as I see it.

mikisch81 · 2019-02-12T22:49:27Z

The tools/tfm folder looks very similar to the existing tools/spm code in terms of the json and py files. Are there plans to merge these in a coming PR? Lots of the code appears to be duplicated.

@bridadan tools/spm contains code generation tools for the 5.11 spm dual-core implementation, in 5.12 we integrate TFM v8m spm implementation which generate different files. Because we still need to support dual-core spm (we are currently in the process of contributing dual-core spm to TFM) we need to keep both generation tools.

bridadan · 2019-02-12T23:01:42Z

I understand @mikisch81. Definitely want to keep compatibility with what was delivered in 5.11. In the future are the tfm and spm tools expected to merge? Or will they always stay separate for versioning reasons?

Looking at the main generate_partition_code.py files, they seem to share over 50% of the same code. If the goal is to merge these tools one day, perhaps the two files could make use of a common module?

mikisch81 · 2019-02-12T23:11:54Z

@bridadan as soon as TFM will have dual-core support we will do a new import and regenerate the needed files again. There is no versioning constraint here

mikisch81 · 2019-02-13T14:16:25Z

Looking at the main generate_partition_code.py files, they seem to share over 50% of the same code. If the goal is to merge these tools one day, perhaps the two files could make use of a common module?

I am working on consolidating tools/spm and tools/tfm together, will update PR when ready.

- Link to bug tracking: https://developer.trustedfirmware.org/T216

- ITS - Crypto - Platform

- Avoid compiling user_setup_stackheap for TF-M secure targets - Align sbrk for TF-M

mikisch81 · 2019-02-19T13:49:13Z

Rebased PR on top of master

mikisch81 · 2019-02-19T14:31:10Z

This needs to be added here : https://github.com/ARMmbed/mbed-os/blob/master/LICENSE . Also the 3rd party code needs license files in its folder (see https://os.mbed.com/docs/mbed-os/v5.11/contributing/license.html - Using different license). Briefly, add bsd 3 clause license file and LICENSE file to describe the license as in the license guide.

@0xc0170 Done

0xc0170 · 2019-02-19T14:51:28Z

I'll run CI. @SenRamakri / @donatieng final review call

0xc0170 · 2019-02-19T14:52:10Z

CI started meanwhile

ashok-rao

Approved based on email discussions. Musca related items will be coming in #9221

mbed-ci · 2019-02-19T18:30:35Z

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 3
Build artifacts

SenRamakri

I have minor comments/questions and would be good if you can answer them, but they are not blockers, so approved.

SenRamakri · 2019-02-19T18:09:20Z

components/TARGET_PSA/TARGET_TFM/COMPONENT_SPE/secure_fw/spm/spm_api.h

+#include "secure_fw/core/tfm_secure_api.h"
+
+#define SPM_INVALID_PARTITION_IDX     (~0U)
+


Does these enums require Doxygen comments?

This file is also imported.

SenRamakri · 2019-02-19T18:15:54Z

components/TARGET_PSA/TARGET_TFM/COMPONENT_SPE/secure_fw/spm/spm_db.h

+#define TFM_PARTITION_TYPE_APP   "APPLICATION-ROT"
+#define TFM_PARTITION_TYPE_PSA   "PSA-ROT"
+
+#define TFM_STACK_SIZE  1024


Should TFM_STACK_SIZE be configurable, driven from config files? On what basis we are hardcoding this to 1024?

Actually each partitions' stack size is configured in their manifest, this is one of our patches to TFM code, see commit fc78640, so TFM_STACK_SIZE is not used anymore.

SenRamakri · 2019-02-19T18:20:31Z

components/TARGET_PSA/TARGET_TFM/COMPONENT_SPE/secure_fw/spm/spm_api.c

+                tfm_spm_partition_set_state(idx, SPM_PARTITION_STATE_IDLE);
+            } else {
+                tfm_spm_partition_err_handler(part, TFM_INIT_FAILURE, res);
+                fail_cnt++;


Minor thing, but can't we just break here(right after fail_cnt++) instead of looping again? Or is it really required to call err_handler for each error?

This file is imported from TFM repository (same as cmsis code), we added patches but they are mainly fixes for issues which were raised during the Musca port.

SenRamakri · 2019-02-19T18:25:14Z

components/TARGET_PSA/TARGET_TFM/interface/include/tfm_api.h

+ */
+#define TFM_CLIENT_ID_IS_NS(client_id) ((client_id)<0)
+
+/* FixMe: sort out DEBUG compile option and limit return value options


FixMe?? Should this be fixed?

This file is also imported.

cmonr · 2019-02-19T21:28:40Z

Final review responses look alright. Merging.

ciarmcom requested review from ashok-rao, deepikabhavnani and a team February 11, 2019 10:00

ciarmcom added the needs: review label Feb 11, 2019

deepikabhavnani approved these changes Feb 11, 2019

View reviewed changes

This was referenced Feb 11, 2019

Add ARM_MUSCA_A1 target #9221

Merged

Update to 2-region model for HEAP and Stack Memory #9571

Merged

0xc0170 added the release-version: 5.12.0-rc1 label Feb 11, 2019

cmonr added needs: work and removed needs: review labels Feb 11, 2019

bridadan reviewed Feb 12, 2019

View reviewed changes

cmonr reviewed Feb 12, 2019

View reviewed changes

cmonr requested review from bulislaw and a team February 12, 2019 22:17

mikisch81 mentioned this pull request Feb 13, 2019

Some build issues with PSA_Target on M2351 #9699

Closed

Edison Ai and others added 11 commits February 19, 2019 15:19

TF-M patch: Fix psa_set_rhandle() issue during CONNECT (TF-M issue #216)

67a4e6d

- Link to bug tracking: https://developer.trustedfirmware.org/T216

Update tfm_importer.json with SHAs of patches

2198d5c

Align existing partitions to work with TF-M

cf3fd85

- ITS - Crypto - Platform

Call tfm_ns_lock_init() on TFM NSPE boot

5dbb8fe

mbed_retarget changes

1db4e46

- Avoid compiling user_setup_stackheap for TF-M secure targets - Align sbrk for TF-M

Build SPM tests only for MBED_SPM targets

60c6740

Adding TF-M integration guide

0ba963a

Consolidating tools/tfm and tools/spm into tools/psa

516af50

Add mbed_app.json for TF-M bare-metal build

01a78e9

Update .travis.yml psa_autogen job with TF-M code generation tool

4a45c16

Re-generate TF-M partition files

9e33f0d

orenc17 approved these changes Feb 19, 2019

View reviewed changes

Add BSD3-clause license file to TF-M folder

6a90da4

0xc0170 approved these changes Feb 19, 2019

View reviewed changes

0xc0170 added needs: CI and removed needs: work labels Feb 19, 2019

ashok-rao approved these changes Feb 19, 2019

View reviewed changes

SenRamakri approved these changes Feb 19, 2019

View reviewed changes

cmonr added ready for merge and removed needs: CI labels Feb 19, 2019

cmonr merged commit 4c04771 into ARMmbed:master Feb 19, 2019

cmonr removed the ready for merge label Feb 19, 2019

mikisch81 mentioned this pull request Feb 19, 2019

Update Toolchain Arm Micro scatter files #9766

Merged

0xc0170 mentioned this pull request Dec 5, 2019

ARMC6: Add a build profile extension with the link-time optimizer enabled #11874

Merged

		#include "secure_fw/core/tfm_secure_api.h"

		#define SPM_INVALID_PARTITION_IDX (~0U)

TF-M sources integration to Mbed-OS #9653

TF-M sources integration to Mbed-OS #9653

Conversation

mikisch81 commented Feb 11, 2019 • edited

Description

Pull request type

Release notes

Reviewers

ciarmcom commented Feb 11, 2019

ciarmcom commented Feb 11, 2019

ciarmcom commented Feb 11, 2019

deepikabhavnani left a comment

Choose a reason for hiding this comment

0xc0170 commented Feb 11, 2019

cmonr commented Feb 11, 2019 • edited

mikisch81 commented Feb 12, 2019

mikisch81 commented Feb 12, 2019

mikisch81 commented Feb 12, 2019

bridadan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

orenc17 Feb 12, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cmonr Feb 12, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bridadan Feb 12, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikisch81 commented Feb 12, 2019

bridadan commented Feb 12, 2019

mikisch81 commented Feb 12, 2019

mikisch81 commented Feb 13, 2019

mikisch81 commented Feb 19, 2019

mikisch81 commented Feb 19, 2019

0xc0170 commented Feb 19, 2019

0xc0170 commented Feb 19, 2019

ashok-rao left a comment

Choose a reason for hiding this comment

mbed-ci commented Feb 19, 2019

SenRamakri left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cmonr commented Feb 19, 2019

mikisch81 commented Feb 11, 2019 •

edited

cmonr commented Feb 11, 2019 •

edited

orenc17 Feb 12, 2019 •

edited

cmonr Feb 12, 2019 •

edited

bridadan Feb 12, 2019 •

edited